接著來講我們在 CI/CD 中做的最後一個操作 —— Deploy dbt docs to GitHub Pages。

dbt docs 的功能跟設定挺單純的，若你的資料模型與 yaml file 都寫完了之後，只要透過簡單的兩個指令 dbt docs generate 以及 dbt docs serve，他就會把模型的內容儲存成 json file 後，轉譯成網頁內容。（文件）

內容十分詳細，不是單純自己寫文件可以達到的精緻度。

除了基本資訊，像是欄位內容與說明、欄位的測試，資料模型的標籤、上下游資料表，甚至連行數、大小以及原始碼都呈現於其中。

針對較為不熟資料的夥伴，他們可以檢視關於資料表與欄位的說明，這也是我之前提到在 documents 中，data marts 的文件說明要寫得盡可能白話的原因。

以前要跟不熟資料的夥伴合作時，要花很多時間釐清我們有什麼資料，以及業務端需求的資料到底是什麼，現在有了這個文件的網頁後，我完全可以先把連結丟給他，請他自己看一下有哪些表、再看看其中有沒有他想要的資料。

當然這並不能直接歸功於這個功能，我們仍然要花不少力氣，優化 data marts 中的資料欄位敘述，以及將資料表做好分門別類，讓業務端可以找到自己的部門或是負責的業務區塊，從中再觀名辨位，確認有沒有相關的資料。

而與熟悉資料的夥伴（略懂 SQL 即可）溝通就更輕鬆了，他們在這份文件中，不只可以看到欄位的描述，同時可以看到資料的上下游，可以一路追蹤資料源頭，過程中還可以將有好奇的 SQL code 片段丟到 GPT，請大師開示開示。

而這樣的合作過程中，若是幸運的話，你可以等有需求的夥伴把他需要的表與欄位提出說明，接著就照著夥伴的需求把 SQL code 變出來就完成需求了！

而在這個過程中，完全不會涉及到資料的操作，只要 BigQuery 的權限有設置好，完全不用擔心夥伴看著 dbt docs 頁面後，「不小心」就執行到轉換，然後回報說資料出問題等等荒謬的錯誤發生。

在 AI 普及的時代中，未來搞不好還可以直接讓有需求的夥伴對 AI 工具提出需求，AI 直接轉譯成 SQL code 後觸發自動化 pipeline，產生他們需要的資料表。

透明又聰明！